Recently, batch processing which has been conventionally performed by a large sized general purpose computer such as a mainframe is increasingly realized on a J2EE system such as a Web Application Server (WAS). J2EE (Java® 2 Enterprise Edition) is one of feature sets of “Java® 2”, a programming language by Sun Microsystems, Inc., in which features required for a server used in a business system for industries or used for electronic commerce are integrated. By utilizing J2EE, the feature set provided with J2EE can be utilized and combined in the development process, and thereby system advantages of low development cost and high reliability can be obtained.
Batch processing is a process in which a sequence of processing steps of reading input data from a specified input stream, executing the logic of an application program based on the input data, and outputting the execution result to an output stream is repeated for a large amount of data. In the case of executing such batch processing on a J2EE system, the execution performance has sometimes been a problem. For example, if, every time data is required for batch processing, the data is acquired from a database; the database has to be accessed very frequently, which may be inefficient.
The following document is considered:    [Non Patent Document 1 Journal of Information Processing Society of Japan, Vol. 35, No. 5 (May 1994)
Conventionally, in order to cope with this, a developer of an application program has manually optimized batch processing by understanding the nature of the application program. For example, by describing in a program a code for collectively acquiring data required for batch processing in advance before the processing, processing efficiency is improved. As a related technique, there is a proposed technique for automatically improving efficiency of batch processing to some extent (see Non Patent Document 1). According to the technique and the related technique described above, it is possible to improve efficiency of sending/receiving data among multiple jobs or job steps included in batch processing.
Still another related technique has been used in a compiler for a vector processor. This compiler first determines data dependency of a program to be compiled, which is the dependency of the program on updated data during the execution of the processing. If there is no such data dependency, the compiler generates codes for reading continuous data in memory collectively to a vector register by using a vector load/store instruction. According to this technique, it is possible to reduce the frequency of reading data from memory and improve the processing efficiency of a program.
The present invention is intended to solve problems with the previous techniques. For example, there are limitations to manually optimize batch processing as described above, because developers have to make efforts to perform optimization for each application program. The objective of the technique of Non patent Document 1 is to optimize input/output relations among multiple jobs in batch processing, and it is not possible to improve efficiency of a single batch job. Furthermore, though a dynamic buffer checking mechanism with the use of input/output jobs is proposed in this technique, this mechanism cannot control what data should be stored in a buffer at what timing.
The approach used in a compiler for a vector processor can be considered to be applicable to a database transaction by regarding a main memory of a computer as a database and CPU registers as a buffer memory. However, contents of a database must be updated every time commitment operation is performed, and this timing is different from the data update timing of the main memory. Therefore, this approach cannot be immediately applied to a database transaction.
Furthermore, this technique assumes that it is possible to completely analyze a target program (such as that the program has a Do All loop) and determine that it does not have data dependency. Therefore, in programming languages which has recently gained popularity, such as Java®, the technique is often not applicable because it is very difficult to statically perform complete analysis for such programs. For example, in special method invocations (specifically, invokevirtual or invokeinterface) in Java®, any one method determined at runtime is selected to call among multiple predefined methods. Therefore, it is impossible to statically determine which method will be invoked, and thus impossible to determine the data dependency.